Un bug ha bloccato banche, aeroporti e ospedali, l’esperto Rabah Djennadi spiega cause e soluzioni.
Nella notte tra giovedì 17 e venerdì 18 luglio si è verificato un bug che ha fatto calare improvvisamente una schermata blu su milioni di server, bloccando l’operatività di banche, aeroporti, trasporti, ospedali e sistemi di pagamento.
Un bug che ha causato danni reputazionali e patrimoniali a molte aziende colpite dal bug dell’azienda americana CrowdStrike, che si occupa di rendere sicuri i dispositivi delle aziende clienti di Microsoft con una soluzione cloud native.
La situazione è stata trattata da diversi punti di vista sia da parte della stampa nazionale che internazionale. Noi di Newsmondo abbiamo deciso di approfondire l’argomento, capire cosa sia successo e come si potrà evitare un blocco simile in futuro. Abbiamo intervistato un esperto informatico, che ha lavorato su molti progetti di portata nazionale e internazionale, il dott. Rabah Djennadi, attualmente informatico del software presso l’azienda N&TS Group S.P.A., leader italiano nei pagamenti elettronici. Durante le sue precedenti esperienze lavorative, il dott. Djennadi ha curato i sistemi informatici di settori strategici del Paese, collaborando anche con banche, fintech e aziende di telefonia di primaria importanza in Italia.
Blackout di Microsoft, l’intervista esclusiva dell’esperto Rabah Djennadi
Dott. Djennadi, ci potrebbe spiegare cosa è successo e che cosa ha bloccato i sistemi informatici indispensabili negli ospedali, banche e per i passeggeri negli aeroporti?
R – “Prima di entrare nel dettaglio della problematica, vorrei spiegare la differenza che esiste tra il bug e l’errore di un software. Il bug è la manifestazione di un problema informatico: nel caso occorso da giovedì scorso è la schermata blu di cui tutti parlano. Mentre l’errore è l’origine del problema che ha portato a un bug. In questo specifico caso l’errore è stato un errore di sicurezza enorme.
Si è parlato di un aggiornamento, cioè una modifica, che ha mandato in tilt i sistemi. Infatti, prima che una modifica del codice arrivi in produzione, deve passare da un sistema di certificazione della qualità in cui il codice del programma viene testato accuratamente.
Un altro aspetto fondamentale è il rilascio graduale dell’aggiornamento, cioè la modifica non deve subito raggiungere tutti i server ma deve prima essere rilasciata solo in un piccolo sottoinsieme di server, agendo in maniera graduale per verificare il corretto funzionamento della modifica e intervenire prontamente nel caso in cui dovessero essere approntati miglioramenti dell’aggiornamento.”
Cosa ritiene allarmante nel blocco dell’operatività di importanti industrie, banche e servizi pubblici?
R – “La cosa che mi ha colpito e più che stupito, in questa vicenda, è stata constatare come un lavoro improvvisato nel progettare un software di aggiornamento sia così impattante e paralizzante su sistemi di valenza globale come, ad esempio, gli aeroporti, gli ospedali e le banche.
Se parliamo solo dell’Italia, oltre a Microsoft, aziende come tre importanti banche del Nord Italia ma anche, come riportano diversi organi di stampa nazionali, Enel, Booking, Wizzair, Ryanair e operatori telefonici quali Postemobile hanno avuto un arresto del funzionamento di parte dei loro sistemi.
Persino alcune fintech quali Mooney ed aziende innovative, sempre come riportato dalla stampa specialistica, non sono rimaste immuni al blackout informatico.
Mi ha impressionato anche come aziende di grandi dimensioni e strategiche per l’economia non abbiano implementato efficienti sistemi di backup. Questi non sono stati solo non equivalenti come estensione e capacità di calcolo al sistema principale ma nemmeno in grado di possedere la capacità di assicurare un servizio minimo da garantire ai clienti all’azienda colpita dal bug.
Questo ci fa capire quanto la tecnologia, come le moderne tecniche di intelligenza artificiale, oltre ad aiutare la produttività, per un guasto od errore possano per contro diventare improvvisamente il collo di bottiglia, la strozzatura che fa saltare il sistema, questo se non implementate con le dovute sicurezze e backup.”
Cosa si sarebbe potuto fare, e quali lezioni a suo avviso possono ricavare le imprese per scongiurare il ripetersi di questi blocchi?
R – “Le aziende dovrebbero rispondere al requisito fondamentale dell’alta affidabilità che richiede un sistema di backup detto: il “Disaster recovery”. Il disaster recovery, o letteralmente in italiano “ripresa dal disastro”, rende necessario avere il backup in area geografica lontana dal sistema principale. Per esempio, in caso di terremoto, il backup dei dati e dei processi non sarà danneggiato.
Ed ancora: assicurarsi che il backup avvenga attraverso altro sistema operativo, ad esempio Linux, che può essere in svariati casi d’uso un’ottima alternativa a Windows, in caso di bug come quello che abbiamo visto. Con questi accorgimenti il backup dei dati e dei processi rimane al sicuro.
Un altro aspetto è quello del collegamento dei server che richiede anche una rete o network alternativo, assicurandosi che il backup sia connesso grazie a un’infrastruttura di networking diversa da quella principale. Una rete alternativa può assicurare la ridondanza e la raggiungibilità nel caso in cui la rete del sistema principale si fosse danneggiata, ed infine assicurare che l’hardware, cioè la componente fisica dei server di backup, sia diverso dall’hardware del sistema principale.
Infine, chiosa l’informatico, il sistema di backup non deve essere sempre un sistema informatico. Per darvi un esempio: se una porta di un hotel o un check-in funziona grazie a un sistema informatico, in caso di bug, l’apertura della porta o del check-in devono comunque essere possibili anche con meccanismi manuali che comunque rispettano gli stessi standard di sicurezza del sistema principale basato sui computer.”
